Object model technology is becoming more popular for building enterprise applications. However, many organizations have already developed relational databases and have their corporate data stored in those databases. Accordingly, it is desirable to provide a mechanism to allow object applications to manipulate objects in relational databases, i.e., write, read, delete and update objects in or from the relational databases. Object-oriented applications are built using object models with inheritance and relationships, whereas relational databases consist of flat tables and foreign keys. It is desired to be able to represent the raw database data as application objects. Databases are queried through a database query language, such as Structured Query Language (SQL), however it is desirable to query object model at the object level and through traversing the object model.
In an object model, for a one-to-many relationship, the source object holds the references to the target objects. This is opposite to a relational database, where the target of the one-to-many relationship stores a foreign key to the source entity. It is desirable to represent a one-to-many relationship in the object model without having the target object have any knowledge, relationship to or foreign key information of the source object. The problem is that this information is required to store the target object into the relational database.
In order to store target objects into the relational database, an existing solution provides the target object in an object model with a many-to-one relationship back to the source object. The shortcomings of having a many-to-one relationship back to the source object is that the target object must have knowledge of the source object. This is intrusive of the object design and prevents other objects in the object model from sharing references to the same target object's class.
Another existing solution provides the target object in an object model with a direct attribute to store the foreign key to the source object. The shortcomings of having a direct attribute to store the foreign key to the source object is that the target.
Another existing solution provides the target object in an object model with a direct attribute to store the foreign key to the source object. The shortcomings of having a direct attribute to store the foreign key to the source object is that the target object must have knowledge of the source object. This is again intrusive of the object design. In this solution, the foreign key attribute must also be maintained by the application's code.
It is therefore desirable to provide a system and method which allow object to relational one-to-many mapping without providing back-reference or direct attributes in the target objects.